home Today's News Magazine Archives Vendor Guide 2001 Search isdmag.com

Editorial
Today's News
News Archives
On-line Articles
Current Issue
Magazine Archives
Subscribe to ISD


Directories:
Vendor Guide 2001
Advertiser Index
Event Calendar


Resources:
Resources and Seminars
Special Sections


Information:
2001 Media Kit
About isdmag.com
Writers Wanted!
Search isdmag.com
Contact Us





Torn From Pages of the Past, Tools for DSP-Centric Design Reflect EDA 'Wild West' Days

By Steven E.Schulz
Integrated System Design
Posted 07/13/01, 08:48:51 AM EDT

An insatiable thirst for instant information is being driven by consumers as well as businesses -- our always connected society expects to have voice, multimedia and data access in real-time.To be sure,desktop PCs are delivery agents,but for engineers the real growth has been in a dataflow-centric, concurrent,priority-driven design architecture.This largely explains the rise in digital signal processing and digital signal processors,the former the goal and the latter a primary means toward it.

DSP-centric designs are characterized by an applications focus that most frequently consists of both hardware and software. Today 's leading DSP processors have specialized architectures that demand much of compiler technology, for manual optimization is becoming too difficult a task.

DSP applications are specialized by nature.Since DSPs are primarily data flow engines,they 're almost always accompanied by a RISC or CISC processor, making most designs multiprocessor and multiarchitecture by default.Thus, it should not be surprising that development tools supporting these applications share the same traits.

While much of the development environment is focused on DSP software, even here the dependencies on DSP architecture are readily apparent. Most DSP tools run on PC platforms,with very professional user interfaces. However,the overall experience through the complete development process (with hardware details) can still be reminiscent of the “Wild West” days of EDA.

We define three categories of DSP tools:system level,implementation and verification. System-level tools perform mathematical analysis,and design filters,systems and communication;they also do behavioral design entry and analysis.At this level,designers generally assume infinite precision and may or may not delineate between hardware and software functionality (some tools assist in hardware/soft- ware partitioning).These tools will also support the technology evaluation phase,which includes se- lection of processors that provide an optimal fit for the algorithms and application needs.

Design implementation tools support the tasks of DSP software design,hardware design and RTOS configuration.Most software development products are bundled as part of an IDE.Such tool sets support DSP software code entry,compilation,debugging,code optimization,task profiling and event analysis.Some tools incorporate graphical dataflow block diagramming and data visualization.On the hardware design side,tools must support processor grouping and task assignment,bus architecture,clock architecture,peripheral selection and timing analysis.

Design verification occurs throughout the development cycle,working at different levels of ab- straction and for different purposes.Some verification features are in IDE tool sets,while others are more specialized.The most common verification technique,simulation,occurs at all levels of abstraction.At the system level,simulation may refer to algorithmic ex- ecution using a high-level language (most often C/C++), or animation of graphical icons representing tasks, mathematical functions,or even spreadsheet macros operating on large streams of data.Sometimes, raw numerical output or waveforms are insufficient to deter- mine proper operation,making data visualization critical to understanding the unfolding design.

Delving deep into DSP design is still not for the faint of heart.Let 's take a look at key challenges facing today 's DSP system designers who use these tools.

Since DSPs are just highly efficient dataflow engines, most designs will also require at least one RISC control processor,generally operating at different clock rates. RISC processors use different memory structures and often different bus protocols and interrupt handling characteristics.The DSP tool environment must accommodate these differences at all stages,but especially in debugging and verification.Hardware/software co-verification is often necessary to ensure proper interaction between algorithmic DSP code running on a target processor and the hardware system surrounding it (memory,buses,peripherals,external environment, etc.).Synchronization of multiple debuggers across processors can be difficult,especially for breakpoint control,master/slave context switches and current state of memory and reverse assembly listings.

Simulation run-time performance trade-offs against accuracy and debugging requirements can be tricky.To achieve reasonable software execution speed,hardware accuracy must be sacrificed.Yet debugging in a concurrent hardware context may require hardware clock accuracy,and the difference can be two or three orders of magnitude.Some EDA tools deal with this,but in general careful design methodology planning is required.

Parallelism support takes on many forms.Automatic compiler optimization must efficiently distribute the workload across many processing units without creating hidden problems.Event analysis and profiling,along with data visualization,is essential to understanding how multiple threads of execution perform.In some cases,users must configure or tune the RTOS to achieve the scheduling and interrupt handling necessary.Architectural optimization and verification as well as code optimization must all comprehend concurrency,synchronization and scheduling concerns.

Libraries and models are often taken for granted,but it is critical that all processors and peripherals, as well as communication protocols,be modeled at appropriate levels of abstraction -- including algorithmic, behavioral, instruction set and clock-cycle accuracy.Detailed timing problems may even require discrete-event simulation.It is especially important to develop a project-verification plan in advance,usually beginning at the technology and processor selection phase.Even so,model performance run-times can vary widely and the wrong choice could cause severe verification bottlenecks.Emulation may be an attractive alternative to bypass simulation bottlenecks,but it also requires significant planning.

A broad array of DSP development tools is available. We now explore some key features and highlights that you can expect from these leading products.

Hyperception Inc.offers a variety of tools for DSP designers.Hypersignal Block Diagram is a hierarchical,visual system design and simulation environment with fast simulation speed and an open architecture for augment- ing its existing large function library,including arithmetic, communications,control,DSP,filters,frame/vector,matrix operations,transforms and user controls.Hypersignal Ride extends the capabilities of Block Diagram to support real-time requirements,with support for industry-standard plug-in DSP and acquisition boards using Windows-based DSP board drivers.Ride links Coff files,and downloads and monitors execution of the DSP (or multiple DSPs).Support is included for symbolic debugging, code profiling,system-level statistics and synchronization of real-time blocks executing at different clock rates.

RGB displays

Hypersignal ImageDSP allows users to construct a block diagram for the image-processing algorithm,then displays execution results as RGB images and histograms integrated within the block diagram view.

Pegasus,from Jovian Systems,provides a complete environment focused on parallel-processing DSP design. The block diagram editor is used for algorithm design and simulation.Special Pegasus blocks in the diagram help the user determine which functions should be mapped into each DSP.This partitioning process determines the ultimate parallelism that can be achieved. Next,the code generator creates single-threaded C source code from the block diagram,used by the designer to create individual source code tasks.After this step,Jovian 's DSParCer tool divides source code into parallel tasks,which can then be compiled and configured for execution. Pegasus performs temporal optimizations, creates communication threads between tasks, removes potential deadlock conditions and optionally substitutes hand-optimized assembly code for signal-processing blocks.Parallel tasks are scheduled by,and communicate through,Jovian 's Parallel C Operating System.

DSP leader Texas Instruments Inc.offers its own Code Composer Studio IDE,supported with a small microker- nel RTOS called DSP/BIOS.Code Composer Studio displays windows for CPU registers,memory,disassembly and breakpoint control,and also contains the optional Parallel Debug Manager for grouping processors and handling multiprocessor broadcast commands (using TI 's GEL scripting language).The environment integrates the TI instruction set simulator (ISS),whose results may be displayed graphically as multidimensional plots or as RGB images (multiprocessor simulation is not yet supported).The compiler tools automatically optimize soft- ware pipelines,remove redundant loops and reorder associative floating-point operations.System-level integration and debug in a parallel-processing DSP environment is enabled through the use of TI 's Extended Development System emulators.

Bops Inc.(the company 's name stands for “billions of operations per second”)develops and licenses the Man-Array series of high-performance,fully scalable broadband DSP cores,which are supported by a complete software development environment.The tool suite includes editors,compilers,debuggers,simulators and FPGA emulation support.The Halo parallelizing C compiler offers VLIW and matrix optimizations,with flexible user control to take full advantage of the ManArray 's three different levels of parallelism.The cycle-accurate system simulator integrates with other emulator boards to support a complete DSP system view.Users may leverage the efficient compiler optimizations performed from C source code,or may use the assembler tools, which provide full instruction-set macro support.

Analog Devices Inc.is serving up VisualDSP++as the development environment for its popular Sharc,Tiger- Sharc and 21x series DSPs.Its key features include a high-performance debugger that incorporates statistical profiling,3-D plotting and multiprocessor debugging. Statistical profiling displays a histogram for each function in the application;click on a function and a second histogram displays utilization for each line of code within that function.VisualDSP++allows synchronized simulation and debugging of multiple processors and architectures within a single debugger interface.The code linker also supports multiprocessing,shared memory and code overlays.

If your host development system must communicate over a network to VMEbus DSP processor boards, look to Pentek 's SwiftNet,part of its COTSware Designer Suite.SwiftNet treats DSP processors as network devices,with full scalability for multiprocessor configurations accessed by design teams.In addition,SwiftTools provides specialized debugging for complex interprocessor tasks,including a unique ability to support code de- velopment on more than one target in parallel.Eonic Virtuoso enables parallel processing in a real-time DSP multiprocessing environment,but uses a “single virtual processor” development environment.Virtuoso automatically routes services and data through multiple parallel communication paths,based upon a user-defined mapping to processor nodes on the network.

DSP designers who are familiar with Synopsys'Cossap will want to investigate CoCentric System Studio.It draws upon the same extensive library of functions as Cossap,as well as the stream-driven simulation engine. System Studio extends beyond Cossap to support heterogeneous modeling of nested data and control models,using a mix of static and dynamic scheduling techniques. The “clustering scheduler”automatically partitions static and dynamic models, feeding them to the appropriate simulation engine for optimal execution. Graphs may be created based upon complex signal calculations,and design partitions may be exported to C, SystemC,VHDL and Verilog for additional verification with HDL-based simulations.

Green Hills Software,maker of the Multi 2000 IDE,had added many new features to this popular software.Multi 2000 now features an incremental debugging capability for faster loading and start times,improved C++debugging and highly intuitive user interface.The event analyzer is extremely configurable,supporting task context switching, semaphore give and take, interrupt, messag- ing and user-defined events.Robust version control is now supported through integration of Clear Case (from Rational Systems). Multi 2000 also contains a performance profiler and graphical project builder.

Mentor Graphics Corp.'s Seamless CVE co-verification environment is often used for system verification of DSP hardware and software in a hardware context.Mentor has redesigned CVE to specifically address DSP system requirements,including multiple memory;data,address and bus spaces;multiple clock frequencies and Harvard architectures.CVE uses “coherent timers ”to synchronize the hardware simulator to the proper hardware clock tick after detail has been lost through the accelerated ISS memory interface,resulting in improved verification accuracy. CVE works with more than 100 RISC and DSP processor models.

Improv Systems Inc.provides a complementary development environment to support its unique Jazz architecture,a software-configurable DSP multiprocessor platform. Solo, Improv 's optimizing cross-compiler, optimizes applications written using a subset of Java, which users may develop through one of several commercial IDEs. The designer creates Java classes to represent tasks,s hared data, ports and even test benches.Composer is used to view or modify a custom VLIW processor from the base Jazz architecture.The Notation debugger incorporates both cycle-accurate and functional simulators,allowing users to debug concurrent aspects of the target platform. Notation can synchronize multiple processors and automatically verify results between ISS and functional simulations.

It is clear that the trend toward real-time, multiprocessing and multiarchitecture DSP Systems is here to stay. Many of the hardware realities previously abstracted away are now affecting performance, functionality -- or both.This will place increased pressure on tools to better integrate the needs of embedded DSP designers into traditional hardware design tools,as well as placing greater emphasis on compatibility and interoperability across products.While many software development features have become commonplace,it is the hardware that will characterize the next generation of products.DSP designers can look forward to more-automated optimizations for parallel systems, increased data visualization options and further couplings with traditional EDA hardware design tools.

   Print Print this story     e-mail Send as e-mail   Back Home

Sponsor Links

All material on this site Copyright © 2001 CMP Media Inc. All rights reserved.